This article provides information which did NOT originate at Apple Computer, Inc., and Apple Computer is not responsible for its content. This information is provided for your convenience. Please contact the author for additional information.
Author: John Wobus, jmwobus@syr.edu
Date: 7/5/1995
This file: http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
General
-------
1) Question: What is DHCP?
Answer: DHCP stands for "Dynamic Host Configuration Protocol".
2) Question: What is DHCP's purpose?
Answer: DHCP's purpose is to enable individual computers on an IP network to extract their configurations from a server (the 'DHCP server') or servers, in particular, servers that have no exact information about the individual computers until they request the information. The overall purpose of this is to reduce the work necessary to administer a large IP network.
3) Question: How is it different that BOOTP or RARP?
Answer: DHCP is based on BOOTP and maintains some backward compatibility. The main difference is that BOOTP was designed for manual pre-configuration of the host information in a server database, while DHCP allows for dynamic allocation of network addresses and configurations to newly attached hosts. Additionally, DHCP allows for recovery and reallocation of network addresses through a leasing mechanism.
RARP is a protocol used by Sun and other vendors that allows a computer to find out its own IP number, which is one of the protocol parameters typically passed to the client system by DHCP or BOOTP. RARP doesn't support other parameters and using it, a server can only serve a single LAN. DHCP and BOOTP are designed so they can be routed.
4) Question: Why shouldn't clients assign IP numbers without the use of a server?
Answer: It is theoretically possible for client-machines to find addresses to use by picking an address out of the blue and broadcasting a request of all the other client machines to see if they are using them. AppleTalk is designed around this idea, and Apple's MacTCP can be configured to do this for IP. However, this method of IP address assignment has disadvantages.
• A computer that needs a permanently assigned IP number might be turned off and lose its number to a machine coming up. This has problems both for finding services and for security.
• A network might be temporarily divided into two non-communicating networks while a network component is not functioning. During this time, two different client-machines might end up claiming the same IP number. When the network comes back, they start malfunctioning.
• If such dynamic assignment is to be confined to ranges of IP addresses, then the ranges are configured in each desktop machine rather than being centrally administered. This can lead both to hidden configuration errors and to difficulty in changing the range. Another problem with the use of such ranges is keeping it easy to move a computer from one subnet to another.
5) Question: Can DHCP support statically defined addresses?
Answer: Yes. At least there is nothing in the protocol to preclude this and one expects it to be a feature of any DHCP server. This is really a server matter and the client should work either way.
6) Question: Can a BOOTP client boot from a DHCP server?
Answer: A DHCP server can be written this way. Since DHCP was developed after BOOTP, it would be logical for most server developers to support this.
7) Question: Can a DHCP client boot from a BOOTP server?
Answer: A DHCP client can be written this way, i.e. to treat a BOOTP reply as an unending lease on the IP address.
8) Question: Can a DHCP client update its DNS entry through DHCP?
Answer: There are options in DHCP through which a DHCP client can request that its DNS entry be updated. DHCP clients will be able to take advantage of planned enhancements to the DNS protocol that will allow dynamic updates through the network.
9) Question: When will the server to server protocol be defined?
Answer: The DHC WG of the IETF is actively investigating the issues in inter-server communication. The protocol should be defined "soon".
10) Question: Is there a DHCP mailing list?
Answer: There are several:
Begin_Table
List Purpose
---- -------
host-conf@sol.eg.bucknell.edu General discussion
dhcp-bake@bucknell.edu DHCP bakeoffs
dhcp-impl@bucknell.edu Implementations
dhcp-serve@bucknell.edu Server to server protocol
Admin requests for the host-conf list should go to host-conf-request@sol.eg.bucknell.edu; admin requests for the other lists should go to listserv@bucknell.edu.
End_Table
11) Question: In a subnetted environment, how does the DHCP server discover what subnet a request has come from?
Answer: DHCP client messages are sent to off-net servers by DHCP relay agents, which are often a part of an IP router. The DHCP relay agent records the subnet from which the message was received in the DHCP message header for use by the DHCP server.
12) Question: Where is DHCP defined?
Answer: In Internet RFCs.
RFC1541 - R. Droms, "Dynamic Host Configuration Protocol", 10/27/1993.
RFC1533 - R. Droms, "Interoperation Between DHCP and BOOTP", 10/08/1993.
RFC1532 - S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", 10/08/1993.
13) Question: Can a client have a home address and still float?
Answer: There is nothing in the protocol to keep a client that already has a leased or permanent IP number from getting a(nother) lease on a temporary basis on another subnet (i.e., for that laptop which is almost always in one office, but occasionally is plugged in in a conference room or class room). Thus it is left to the server implementation to support such a feature. I've heard that Microsoft's NT-based server can do it.
14) Question: How can I relay DHCP if my router does not support it?
Answer: A server on a net(subnet) can relay DHCP or BOOTP for that net. Windows NT can be set up that way.
15) Question: How do I migrate my site from BOOTP to DHCP?
Answer: I don't have an answer for this, but will offer a little discussion. The answer depends a lot on what BOOTP server you are using and how you are maintaining it. If you depend heavily on BOOTP server software to support your existing clients, then the demand to support clients that support DHCP but not BOOTP presents you with problems. In general, you are faced with the choice:
1. Find a server that is administered like your BOOTP server only that
also serves DHCP. For example, one popular BOOTP server, the CMU
server, has been patched so that it will answer DHCP queries.
2. Run both a DHCP and a BOOTP server. It would be good if I could find
out the gotcha's of such a setup.
3. Adapt your site's administration to one of the available DHCP/BOOTP
servers.
4. Handle the non-BOOTP clients specially, e.g. turn off DHCP and
configure them statically: not a good solution, but certainly one that
can be done to handle the first few non-BOOTP clients at your site.
16) Question: Can you limit which MAC addresses are allowed to roam?
Answer: Sites may choose to require central pre-configuration for all computers that will be able to acquire a dynamic address. A DHCP server could be designed to implement such a requirement, presumably as an option to the server administrator. See section below on servers that implement this.
17) Question: Can DHCP support remote access?
Answer: PPP has its own non-DHCP way in which communications servers can hand clients an IP address called IPCP (IP Control Protocol) but doesn't have the same flexibility as DHCP or BOOTP in handing out other parameters. Such a communications server may support the use of DHCP to acquire the IP addresses it gives out. This is sometimes called doing DHCP by proxy for the client. I know that Windows NT's remote access support does this.
A feature of DHCP under development (DHCPinform) is a method by which a DHCP server can supply parameters to a client that already has an IP number. With this, a PPP client could get its IP number using IPCP, then get the rest of its parameters using this feature of DHCP.
SLIP has no standard way in which a server can hand a client an IP address, but many communications servers support non-standard ways of doing this that can be utilized by scripts, etc. Thus, like communications servers supporting PPP, such communications servers could also support the use of DHCP to acquire the IP addressees to give out.
I am not currently aware of any way in which DHCP can support client-computers served solely by PPP or SLIP. Such a computer doesn't have the IEEE-style MAC address that DHCP requires to act as its key to determining which client-computer is which within the same subnet. Communications servers that acquire IP numbers for their clients via DHCP run into the same roadblock in that they have just one MAC address, but need to acquire more than one IP address. One way such a communications server can get around this problem is through the use of a set of unique pseudo-MAC addresses for the purposes of its communications with the DHCP server. Another way (used by Shiva) is to use a different "client ID type" for your hardware address. Client ID type 1 means you're using MAC addresses. However, client ID type 0 means an ASCII string.
18) Question: What are the Gotcha's?
Answer:
1. A malicious user could make trouble by putting up an unofficial DHCP server.
• The immediate problem would be a server passing out numbers already belonging to some computer yielding the potential for two or more "innocent bystander" nodes ending up with the same IP number. Net result is problems using the nodes, possibly intermittent of one or the other is sometimes turned off.
• A lot of problems are possible if a renegade server manages to get a client to accept its lease offering, and feeds the client its own version of other booting parameters. One scenario is a client that loads its OS over the network via tftp being directed to a different file (possibly on a different server), thus allowing the perpetrator to take over the client. Given that boot parameters are often made to control many different things about the computers' operation and communication, many other scenarios are just as serious.
*Note that BOOTP has the same vulnerabilities.
2. The "broadcast flag": DHCP includes a way in which client implementations unable to receive a packet with a specific IP address can ask the server or relay agent to use the broadcast IP address in the replies (a "flag" set by the client in the requests). The definition of DHCP states that implementations "should" honor this flag, but it doesn't say they "must". Some Microsoft TCP/IP implementations used this flag, which meant in practical terms, relay agents and servers had to implement it. A number of BOOTP-relay-agent implementations (e.g. in routers) handled DHCP just fine except for the need for this feature, thus they announced new versions stated to handle DHCP.
3. Some of the virtual LAN schemes, i.e., those that use the packet's IP number to decide which "virtual LAN" a client-computer is on for the purposes of TCP/IP, don't work when using DHCP to dynamically assign addresses. DHCP servers and relay agents use their knowledge of what LAN the client-station is on to select the subnet number for the client-station's new IP address whereas such switches use the subnet number sent by the client-station to decide which (virtual) LAN to put the station on.
4. Routers are sometimes configured so that one LAN on one port has multiple network (or subnet) numbers. When the router is relaying requests from such a LAN to the DHCP server, it must pass along as IP number that is associated with one of the network (or subnet) numbers. The only way the DHCP server can allocate addresses on one of the LAN's other network (or subnet) numbers is if the DHCP server is specifically written to have a feature to handle such cases, and it has a configuration describing the situation.
5. The knowledge that a particular IP number is associated with a particular node is often used for various functions. Examples are: for security purposes, for network management, and even for identifying resources. Furthermore, if the DNS's names are going to identify IP numbers, the numbers, the IP numbers have to be stable. Dynamic configuration of the IP numbers undercuts such methods. For this reason, some sites try to keep the continued use of dynamically allocatable IP numbers to a minimum.
6. With two or more servers serving a LAN, clients that are moved around (e.g. mobile clients) can end up with redundant leases. Consider a home site with two DHCP servers, a remote site with DHCP services, and a mobile client. The client first connects to the home site and receives an address from one of the two serves. He/she then travels to the remote site (without releasing the lease at the home site) and attempts to use the acquired address. It is of course NAK'ed and the client receives an address appropriate for the remote site. The client then returns home and tries to use the address from the remote site. It is NAK'ed but now the client broadcasts a DHCPDISCOVER to get a address. The server that holds the previous lease will offer the address back to the client but there is no guarantee that the client will accept that address; consequently, it is possible for the client to acquire an address on the other server and therefore have two leases within the site. The problem can be solved by using only one server per subnet/site and can be mitigated by short lease lengths. But in a very mobile environment, it is possible for these transient servers to consume more than their fair share of addresses.
7. If departments, offices, or individuals run DHCP servers with their own small address pools on LANs shared by other departments, offices, or individuals, they can find that their addresses are being used by anyone on the LAN that happens to set their IP configuration to use DHCP.
Info on Implementations
-----------------------
19) Question What freeware DHCP servers are available?
Answer: This is not necessarily a complete list.
950415 Bootp server:
Bootp 2.4.3 (not DHCP, but with the "DHCP patches" mentioned below,
can handle DHCP requests)
ftp://ftp.mc.com/pub/bootp-2.4.3.tar.Z
950425 Patched bootp server:
Bootp server version 2.4.3 with DHCP patches (does static allocation
22) Question: What are the DHCP plans of major client-software vendors?
Answer:
MacTCP: will support it; I have no news on when or what version.
Windows95: will support it and will not support BOOTP!
Novell: has plans for client support later in 1995
IBM AIX: will support it; I have no news on when or what version.
OS/2: will support it; I have no news on when or what version.
23) Question: What Routers forward DHCP requests?
Answer: This is not necessarily a complete list.
Cisco: (from Cisco FAQ) Routers running GSYS version 9.21(4) and 10.0(3) as well as later releases.
Wellfleet/Bay: (from Wellfleet FAQ) DHCP is supported by enabling BOOTP support (with transmission and/or reception as needed).
3Com Netbuilder: Version 7.2 software can support DHCP relaying through the use of its generic UDP Helper service. Version 8.0 and later officially supports DHCP.
Xyplex: Word is that release 5.1 slated for first quarter 1996 will support it.
24) Question: What Routers include DHCP servers?
DHCP requires disk storage (or some other form of reliable non-volatile storage), making the task of DHCP service compatible with servers but incompatible with dedicated routers. There are a number of server types that can be configured to both route and serve DHCP (especially all-in-one "Internet Gateways" designed to be web servers, firewalls, etc.), but no dedicated routers.
25) Question: What Routers use DHCP to configure their IP addresses?
Answer: The DHCP RFC spedifically says that DHCP is not intended for use in configurng routers. The reason is that in maintaining and troubleshooting routers, it is important to know its exact configuration rather than leaving that to be automatically done, and also that you do not want your router's operation to depend upon the working of yet another server.
It may be possible to configure some types of more general-purpose computers or servers to get their addresses from DHCP and to act as routers. Also, there are remote access servers, often which are usually not true routers, which use DHCP to acquire addresses to hand out to their clients.
26) Question: What Servers forward DHCP requests?
Answers: Windows NT's 3.51 Service Pack 3 (and 4) includes a BOOTP (& DHCP) relay agent as part of "Multi Protocol Router". 3.51). For Novell servers, there are NLMs that forward BOOTP requests, thus DHCP requests. The "BOOTPFWD NLM" is included in NetWare 4.1. You can get this support in NetWare 3.11 and 3.12 also, but you must apply the TCP31A.EXE patch which is located on Netwire. Here are two such NLMs that are available online:
Also for Novell servers, the DHCP server that comes with NetWare/IP 2.2 can be configured to be just a BOOTP/DHCP forwarding agent.
27) Question: Which implementations support or require the broadcast flag?
Answer: The broadcast flag is an optional element of DHCP, but a client which sets it works only with a server or relay that supports it.
Clients
-------
• Microsoft Windows NT -DHCP client support added with version 3.5 sets the broadcast flag. Version 3.51 and later no longer set it. The exception is in the remote access support: it sets the flag when it uses DHCP to acquire addresses to hand out to its PPP clients.
• tcp/ip-32 for Microsoft Windows for Workgroups (WFW)- Version 3.11a sets it, but version 3.11B doesn't.
• Microsoft Windows 95 - Does not set the broadcast flag.
28) Question: How can I run Windows 95 without a DHCP server?
Answer: Not really a DHCP question, but it has been asked a lot, particularly by sites for which changing from BOOTP represents a lot of work. Some choices:
1. Use no server at all for the Windows 95 clients: set the addresses in each client's setup.
2. Install a non-Microsoft TCP/IP stack for Windows 95 that supports BOOTP.
3. Switch from your current BOOTP server to one that supports both BOOTP and DHCP.
4. I know nothing about it, but there exists code to make Windows 95 run BOOTP:
A Document that addresses this question is the Windows 95tm Networking FAQ, http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html
29) Question: Do any servers limit the MAC addresses that may roam?
Answer: IBM's AIX and OS/2 WARP DHCP servers.
30) Question: What analyzers decode DHCP?
Answer: Release 5.0 of Network General Corporation's Sniffer software. I believe one of the free Unix implementations has included in its distribution a program that captures and decodes BOOTP and DHCP negotiations. Microsoft's SMS includes a protocol analyzer called "Network Monitor" that decodes DHCP. All NT software includes a remote agent for it.
31) Question: What administation tools administer DHCP configurations?
Answer: Quadritek's QIP network administration product includes an interface to Competative Automation's JOIN DHCP server.
32) Question: What are the Gotcha's specific to various implementations?
Answer: In many cases, new releases have solved the problems that have been identified with various DHCP implementations.
1. There have been servers that are inflexible as to the list of configuration parameters they were able to serve. If your client requires certain parameters, you could find such a server unusable.
2. I hate to cast wide suspicions, but I've heard occasional word on client DHCP implementations that do not implement the entire protocol. Doing so requires that the software module be able to wake up again after a specified period of time and "renew the lease", i.e., ask to continue using the IP number. This is at least one feature of DHCP that is very hard to implement in some simpler systems.
3. There are a number of issues regarding the patched bootp servers. These have been reported to re DD2.4.3:
- 'When run from inetd, I had problems with "Could not bind port" and DHCP request failure. I don't know why, and the problem went away when bootpd is run as a daemon.'
- 'Unless you set "dl" to some value in the bootptab file, the DHCP lease time, renewal time and prebinding time will be rubbish, which will cause occasional renewal problems.' One symptom you might see is Microsoft DHCP implementations using 5-minute leases, which is their default. Other implementations may not run at all.
4. Early Microsoft DHCP client implementations required the broadcast bit. Current ones do not.
5. I have heard a vague complaints about the Microsoft implementations of DHCP: that it does not follow the standards. I could use details.
6. Early Apple Open Transport implementations did not always fill out packets to BOOTP's 300-byte minimum, thus BOOTP forwarding agents that follow the BOOTP RFC and discard such packets end up discarding such DHCP packets, causing some of the functions to fail. Open Transport 1.1 fixes this.
7. The very first announced release of Carnegie Mellon's server, dhcp-3.3.6, circa March 1996 has shown signs of needing to be shaken out to be more easily compiled outside of its development environment.
Article Change History:
03 Jul 1996 - Corrected typographical error.
11 Jun 1996 - Added new questions and answers from the web.
